S.O.L.I.D. Principles Around You - DEV Community

#programming #software-development #object-oriented-design
Cover image for S.O.L.I.D. Principles Around You

In this article, I want to briefly go through SOLID principles (the acronym that stands for five basic principles of object-oriented programming and design) supplying each of them with real-world visual examples to make those principles more understandable, readable and memorizable.

If you want to see code examples instead you may take a look at variety of tree data structure implementations in JavaScript like Binary Search Tree, AVL Tree, Red-Black Tree, Segment Tree or Fenwick Tree.

So let’s move on!

S — Single Responsibility Principle

[a.k.a SRP] A class should have only a single responsibility. Only one potential change in the software’s specification should be able to affect the specification of the class.

O — Open/Closed Principle

[a.k.a OCP] Software entities should be open for EXTENSION, but closed for MODIFICATION. Allow behavior to be extended without modifying the source code.

L — Liskov Substitution Principle

[a.k.a. LSP] Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

I — Interface Segregation Principle

[a.k.a. ISP] Many client-specific interfaces are better than one general-purpose interface. No client should be forced to depend on methods it does not use.

D — Dependency Inversion Principle

[a.k.a. DIP] One should depend upon abstractions, not concretions.

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

The plug doesn’t care which type of wire it uses, it just needs wires that conduct electricity.

I hope these illustrations have been useful for you :)

{
  "type": "file",
  "name": "S.O.L.I.D. Principles - DEV Community.md",
  "path": "/resources/articles/S.O.L.I.D. Principles - DEV Community.md",
  "modTime": "2025-10-22T15:24:29.758Z",
  "mime": "application/markdown",
  "size": 5757,
  "content": {
    "_schema": "Article",
    "_type": "Article",
    "articleBody": "#programming #software-development #object-oriented-design\n![Cover image for S.O.L.I.D. Principles Around You](https://res.cloudinary.com/practicaldev/image/fetch/s--twyS3ck3--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://dev-to-uploads.s3.amazonaws.com/i/0qazxkim2uf50lnwjkhx.png)\n\nIn this article, I want to briefly go through [SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) principles (the acronym that stands for five basic principles of object-oriented programming and design) supplying each of them with real-world visual examples to make those principles more understandable, readable and memorizable.\n\n> If you want to see code examples instead you may take a look at [variety of tree data structure implementations](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree) in **JavaScript** like [Binary Search Tree](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree/binary-search-tree), [AVL Tree](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree/avl-tree), [Red-Black Tree](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree/red-black-tree), [Segment Tree](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree/segment-tree) or [Fenwick Tree](https://github.com/trekhleb/javascript-algorithms/tree/master/src/data-structures/tree/fenwick-tree).\n\nSo let’s move on!\n\n## [](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17#s-single-responsibility-principle)S — Single Responsibility Principle\n\n\\[a.k.a [SRP](https://en.wikipedia.org/wiki/Single_responsibility_principle)\\] A class should have only a single responsibility. Only one potential change in the software’s specification should be able to affect the specification of the class.\n\n[![Single Responsibility Principle](https://res.cloudinary.com/practicaldev/image/fetch/s--Qh1_I3hH--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/xabfs57cezxegih8uh2f.png)](https://res.cloudinary.com/practicaldev/image/fetch/s--Qh1_I3hH--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/xabfs57cezxegih8uh2f.png)\n\n## [](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17#o-openclosed-principle)O — Open/Closed Principle\n\n\\[a.k.a [OCP](https://en.wikipedia.org/wiki/Open/closed_principle)\\] Software entities should be open for EXTENSION, but closed for MODIFICATION. Allow behavior to be extended without modifying the source code.\n\n[![Open/Closed Principle](https://res.cloudinary.com/practicaldev/image/fetch/s--pagpCyfX--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/fv3xpd9kkfgntqby9eg6.png)](https://res.cloudinary.com/practicaldev/image/fetch/s--pagpCyfX--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/fv3xpd9kkfgntqby9eg6.png)\n\n## [](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17#l-liskov-substitution-principle)L — Liskov Substitution Principle\n\n\\[a.k.a. [LSP](https://en.wikipedia.org/wiki/Liskov_substitution_principle)\\] Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.\n\n[![Liskov Substitution Principle](https://res.cloudinary.com/practicaldev/image/fetch/s--ArU0mGdu--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/7wdzib8lqfq9bcstfqu3.png)](https://res.cloudinary.com/practicaldev/image/fetch/s--ArU0mGdu--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/7wdzib8lqfq9bcstfqu3.png)\n\n## [](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17#i-interface-segregation-principle)I — Interface Segregation Principle\n\n\\[a.k.a. [ISP](https://en.wikipedia.org/wiki/Interface_segregation_principle)\\] Many client-specific interfaces are better than one general-purpose interface. No client should be forced to depend on methods it does not use.\n\n[![Interface Segregation Principle](https://res.cloudinary.com/practicaldev/image/fetch/s--58sXrCsO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/rnwds5cv5qcodlam1wc6.png)](https://res.cloudinary.com/practicaldev/image/fetch/s--58sXrCsO--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/rnwds5cv5qcodlam1wc6.png)\n\n## [](https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17#d-dependency-inversion-principle)D — Dependency Inversion Principle\n\n\\[a.k.a. [DIP](https://en.wikipedia.org/wiki/Dependency_inversion_principle)\\] One should depend upon abstractions, not concretions.\n\n-   High-level modules should not depend on low-level modules. Both should depend on abstractions.\n-   Abstractions should not depend on details. Details should depend on abstractions.\n\n[![Dependency Inversion Principle](https://res.cloudinary.com/practicaldev/image/fetch/s--yw39zKqE--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/wugaxuqznqow3wzgp8hr.png)](https://res.cloudinary.com/practicaldev/image/fetch/s--yw39zKqE--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/wugaxuqznqow3wzgp8hr.png)\n\nThe plug doesn’t care which type of wire it uses, it just needs wires that conduct electricity.\n\nI hope these illustrations have been useful for you :)\n",
    "author": {
      "_type": "Person",
      "name": "twitter:Trekhleb"
    },
    "headline": "S.O.L.I.D. Principles Around You - DEV Community",
    "reviewRating": {
      "bestRating": 5,
      "worstRating": 1
    },
    "url": "https://dev.to/trekhleb/s-o-l-i-d-principles-around-you-1o17"
  }
}